+1 - Anyone have the answer?

This thread is 7 YEARS OLD and I hit the same problem as all of you after upgrading my project compat to Xcode 12+ I tried: Clean and Rebuild .... then spend hours googling what other people did in my situation, or what was the proper way to set up a splashscreen storyboard with a single PNG in the middle of it. Move PNG to Images.xcassets (and Rebuild ... reboot phone and rebuild... delete from phone, reboot, rebuild) Move Splash.storyboard to the main source folder (and Rebuild ... delete from phone, reboot phone and rebuild) Move PNG back to root of project, remove, re-add, rebuild... delete from phone, reboot, and rebuild... BE SURE TO SAVE .xcassets, .xcodeproj, and .xcworkspace between edits and all the above dark incantations, round 2. Uninstall and re-install Xcode Sacrifice a goat to each of a 1x, 2x, and 3x life-scale effigy of Steve Jobs Ultimately what worked was creating a new Xcode project and meticulously copying all the salient files and settings from the old project. And the sad thing is, I know I've had this exact problem with this exact same app I maintain several other times over the last 3 years. Never with any logical cause, never with the same solution (or certainty as to *which* solution actually did the trick.) I don't know if there is a subtle hint from the IDE ux I am missing (maybe because I am colorblind?) or if there is a recurring bug in Xcode over the years regarding cache coherency between the IDE and the actual files on disk, or if it is a Bertrand Russel paradox of actual folders vs. Xcode make-believe folders with Xcode file references and unix file aliases attempting to resolve the image set of all image sets which do not contain themselves... yet somehow do contain my image assets.... BUT PLEASE Apple, if you must FORCE us to use your IDE, can't you at least test it??? And no, I can't reproduce the issue for you in a test project -- the fundamental issues with Xcode usage are issues fundamentally because they appear non-deterministic from the perspective of a user. More constructively: re-visit the entire project file editing paradigm with a special attention to finitely enumerating (and minimizing!) all possible state transitions and verifying their functionality in your unit tests. Use a strategy that produces convergently consistent results. Reduce the number of places where the "location" of an asset is copied around the project files -- ideally to one. Or zero, if you just use convention over configuration, and actively re-query the folders every time. Consider removing the abstractions and endless redundant manifest files in the project system, and embrace an approach that is 1:1 with the file system - and don't force me to use A SEPARATE IDE to debug the stale references in the horribly verbose plist-formatted *.apple-fu-wizardy-foobar files. I'm certainly not a perfect dev, I make all those same kinds of mistakes in systems I build - that's how I know for certain, with no actual proof, that these project-system over-complications are to blame for Xcode's legacy of ridiculous un-provable instability. -- but! I'm not a multi-billion dollar corporation with the resources to get stuff correct the first time... or the second time... OR SEVEN YEARS LATER.

Also worked in Xcode 12.4 (12D4e) (EDIT - nevermind, stopped working again 5 minutes later.)